Sophisticated wireless data communications devices, systems and networks, such as cellular telephones and wireless LAN transceivers, are in widespread use worldwide. There is increasing need to support more data communication devices, with larger numbers of radio frequency (RF) as well as wired interfaces (e.g., Ethernet) for handling an increased number of user terminals within each network. Further, the rapidly increasing capabilities of the user terminals and wireless communication networks leads to a substantial increase in their data processing power as well as their supported protocol stacks. All of these, however, increase the complexity and scale of the wireless terminals, systems and networks, and drives the need to test the terminals and networks (i.e., the Devices Under Test or DUTs) during design and manufacturing. Manufacturers, vendors and users therefore have a greater need for more efficient, more cost-effective, and more flexible wireless data communications test systems.
Traditional methods of constructing such wireless communications test systems have relied on assemblies of self-contained line cards or modules. In traditional telecommunications switches, a line card is a printed circuit board that includes all of the facilities for maintaining a telephone line. In the context of the wired and wireless communications test systems described herein, a line card or module is a printed circuit board with various components mounted on the printed circuit board for performing a test and/or a communications function. Each line card is connected either physically (e.g., through a cable) or via electromagnetic coupling (e.g., using antennas) to one interface of the DUT. There are hence as many modules as there are DUT interfaces to be tested. Each line card, being self-contained, holds all of the necessary processing capabilities to support all of the protocols and data transmission functions of the wireless or wired interface that it is intended to test. Testing is generally conducted by activating one or more line cards, configuring them to establish connections to their corresponding DUT interfaces, and then creating test traffic flowing between the line cards through the DUT or System Under Test (SUT). The test traffic is then processed and analyzed to derive test results.
FIG. 1 depicts a representative example of such a test setup for testing a wireless DUT 100, which may contain one or more wireless (radio) interfaces 103, 106 and one or more wired interfaces 109. The wireless interfaces of DUT 100 are connected via sets of RF cables 102, 105 to wireless traffic generator and analyzer line cards 101, 104, which may (in this example) support different protocols, such as IEEE 802.11n and IEEE 802.11ac respectively. The wired interface of DUT 100 is connected via cable 108 to wired traffic generator and analyzer line card 107, which may support a wired protocol such as Ethernet. The test system is usually set up and managed by test configuration and management system 110, which reads the necessary test setup data 112, determines the appropriate settings and control commands for line cards 101, 104, 107, and controls these line cards via configuration and management interface 111.
Normal operation of the system depicted in FIG. 1 is reasonably straightforward. Test configuration and management system 110 obtains test setup data 112 and configures the line cards to communicate with DUT 100, execute the necessary wireless and wired protocols, generate and transmit traffic directed to the DUT, and receive and analyze traffic from the DUT. As it is usually necessary to for the test system to scale to large numbers of DUT interfaces, the processing power required to generate and analyze the totality of the test traffic normally far exceeds the capability of the test configuration and management system, or any one line card. Therefore, each traffic generator and analyzer line card contains all of the facilities necessary to execute the appropriate protocols and generate and analyze the required traffic.
A high-level block diagram of a typical traffic generator and analyzer line card is depicted in FIG. 2. As shown, line card 150 usually comprises a bank of one or more field programmable gate arrays (FPGAs) organized in groups 162, 163, as well as a group of one or more CPUs 161. For increased processing power, CPUs 161 may contain multiple cores. Line card 150 accepts configuration and control commands from configuration and management interface 156 and translates them to internal control commands in protocol and hardware/software traffic control functions unit 155. These control commands set up a software traffic generator and analyzer 151, a hardware traffic generator 152, a hardware traffic analyzer 154, and sets of software protocol stacks 153. These traffic generator, traffic analyzer, and protocol stack units then send and receive packets to/from a Medium Access Control (MAC) functions block 157, which in turn performs Open Systems Interconnection (OSI) Layer 2 protocol processing and sends/receives packets to/from a physical layer (PHY) module 158. PHY module 158 transmits/receives packets to the DUT using either a wired (e.g., Ethernet) or wireless (e.g., radio) interface.
Partitioning of line card 150 into these various functional blocks, such as software traffic generator/analyzer 151 vs. hardware traffic generator 152 and hardware traffic analyzer 154, is done in order to cope with the differing complexity and processing rate requirements of different kinds of protocol functions and test functions. For example, test functions at OSI Layer 7 (the Application Layer) is normally implemented using software traffic generator/analyzer 151, as generating and processing test traffic at Layer 7 is prohibitively complex for hardware implementation, such as in FPGAs. On the other hand, accurately generating and analyzing test traffic at maximum line rates, as is typically performed for OSI Layer 3 or Layer 2 testing, is usually implemented using hardware traffic generator 152 and hardware traffic analyzer 154, as it is very difficult for software systems to consistently and accurately function at such high packet rates. Similarly, protocol stacks are typically implemented in software, such as in software protocol stack sets 153, as they do not have significant performance requirements, but are too complex for realization in hardware. Finally, MAC and PHY functions are almost always implemented in hardware as they are simple but required to operate at very high rates.
It is apparent from FIG. 1 and FIG. 2 that each line card contains substantially identical functional blocks implemented in substantially identical ways. This is to permit maximum flexibility in testing; if the line cards implemented different functions, it would be necessary to disconnect and reconnect cables to reconfigure the system topology every time the test configuration was altered. For example, if in a particular test scenario the 802.11n traffic generator/analyzer line card 101 in FIG. 1 were used for application layer testing, its hardware traffic generator/analyzer elements (such as 150 and 154 in FIG. 2) would remain idle; on the other hand, if in the same scenario the 802.11ac traffic generator/analyzer line card 104 in FIG. 1 were used for bulk traffic generation, then the software traffic generator/analyzer elements (such as 151 in FIG. 2) would be unused.
A problem with this approach to implementing test systems is that the overall cost of the test system becomes very high due to the comparatively low utilization of the various elements. In any given test scenario it is extremely rare to find all of the different elements (e.g., the elements identified in FIG. 2) being simultaneously used. However, it is necessary to build the line cards of the test system in a homogeneous fashion with all of the elements present; otherwise, it would be time-consuming and tedious to manually rewire the test system for every test to improve utilization, assuming that heterogeneous line cards were used with differing capabilities for each line card.
A second disadvantage of this approach is that the maximum processing power available at any given line card is limited by the space and capacity of the line card itself, which may in turn be constrained by external factors such as the available chassis space and the size of the power supply. This makes it difficult to cope with ever-increasing data rates being achieved by both wired and wireless DUT interfaces. For example, a single line card might be able to support the processing power required to sustain 10 gigabits/second of traffic, but may not be able to contain the FPGAs and CPUs required to sustain 100 gigabits/second of traffic.
A third disadvantage of this approach is that the architecture and capabilities of the line card are fixed in all dimensions when the line card is originally designed. For example, a particular configuration and interconnection of FPGAs and CPUs may be created on the line card to support the anticipated needs of a target test setup. However, as wireless communications technology evolves, new protocols may arise that were not foreseen. It is then possible that while the FPGAs on the line card are adequate to the hardware requirements, their interconnection with the CPUs may not be sufficiently powerful to support the software needs of the new protocols. In this case the entire line card will need to be discarded and a new line card designed, in spite of the fact that a large portion of the existing line card is in fact still usable.
Existing wireless device test systems therefore suffer from significant shortcomings. There is hence a need for improved wireless data communication test systems and methods. A system that can improve the utilization of the elements comprising the test system is desirable. It is preferable for such a system to allow the processing power available to a line card to be expanded beyond the limits of space and power capacity of a single card. Finally, a system that permits individual elements of a line card to be upgraded to support increased protocol or traffic generation requirements, without necessitating the abandonment of the entire line card, is desirable.